• 菜雞行為：把程式碼交出去當成已經交付
• STAR 階段：T (Task)
• 本篇定位：定義接手者完成操作、驗收、部署與回復所需的最小資訊。

這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境（Situation）、任務（Task）、行動（Action）與結果（Result）。每個故事會拆成三天：第一天談 S，還原當時的情境與我原本的理解；第二天談 T，釐清真正的任務、限制與完成條件；第三天則合併 A 與 R，整理我採取的行動、造成的結果，以及後來學到的事。

這篇在三日故事中的位置

Day 22｜程式碼交出去後，我才發現別人根本接不起來，停在接手失敗：缺的知識全在我腦裡。本篇只定義任務：一次交付至少要給接手者什麼；怎麼做，留給 Day 24。

「補文件」是我的搶答，讓人接得起來才是任務

看見缺口後，我的第一反應又是搶答：補 README、畫架構圖、寫安裝指南，彷彿文件夠多就算交付。但「補文件」是候選方案，不是任務。續用虛構的粉鳥工單服務：逾期提醒排程的交付任務，是讓接手的開發者不靠我在場，就能操作、驗證、部署與回復。文件只是手段，種類與厚度由這個目的反推。

接手者要做的事，決定要留的資訊

我把接手者的工作攤開：理解變更、啟動操作、驗證功能、出事回復。每件工作對應一種最小資訊與驗收方式：

表格之外還有未知要先確認：接手者是誰、對系統熟到什麼程度、哪些環節已有共用文件不必重寫。答案會改變清單長度，得先問；文件放哪個平台，可以延後。

限制與回復方式也是交付內容

最容易被我省略的兩項，剛好最重要。一是限制與未完成事項：已知邊界與沒處理的例外，寫出來不是自曝其短，而是讓接手者不必重踩一次。二是回復方式，且必須和部署方式一致：用設定切換上線，就要能切回去；沒演練過的回復步驟等於沒寫。非目標也要說清楚：不含重寫架構文件，不保證涵蓋未來需求。

交付由接手者的工作反推

任務不是補文件，是讓人接得起來；資訊由接手者要做的事決定；限制、未完成與回復方式是交付內容。

今天可以帶走的練習

挑一項準備交接的功能，花四十分鐘，用《完成定義表》列出變更、操作、設定、測試、限制、部署、回復與負責人，各附完成條件與證據形式。產出是一頁定義表，驗收是請另一位讀者指出哪一列他最沒把握接手。功能很小、自己會繼續維護時不必完整填表。

還是 Day 08 那張《完成定義表》，這次重點落在最後一層。

對應工具：《完成定義表》。

# 完成定義表

用途：區分程式完成、功能完成、整合完成與交付完成。
使用時機：成果要交給別人操作、驗收或維護時。
不必使用：自己短期內繼續維護、口頭交接已足夠時。

| 層次 | 完成條件 | 證據 |
| --- | --- | --- |
| 程式完成 | 程式碼合併且測試通過 | 測試紀錄 |
| 功能完成 | 接手者能操作與驗證 | 操作步驟與驗證方式 |
| 整合完成 | 在正式環境跑得起來 | 部署紀錄 |
| 交付完成 | 限制、部署與回復都有文件 | 演練過的回復步驟 |

提醒：完成條件由接手者的工作決定，不由文件種類決定。

下一篇

任務定義好了：讓接手者不靠我也能操作、驗證與回復。Day 24｜我替成果建立最小交付證據包，會交代我如何把這份定義收進一份文件，以及結果。